In troubleshooting failures or performance of protected networks, it is often required to determine the sequential order of relevant logged events of all nodes in a network, or the timestamps of a particular event across all the nodes in the network. For example, a protected network may include Optical Transport Network (OTN) as defined in ITU-T G.709 (December 2009) “Interfaces for the Optical Transport Network (OTN)” and G.798 (October 2010) “Characteristics of optical transport network hierarchy equipment functional blocks,” the contents of each are incorporated by reference herein. An OTN protected network may also include a control plane which performs automatic service provisioning and restoration. Thus, when a mesh-protected circuit fails and mesh restoration occurs, an overwhelmingly large number of events are generated by both the control plane and a data plane at various nodes in the network. To diagnose a root cause of a mesh restoration failure or high switching time, it is critically important to find out the sequential order or the timestamps of relevant events across the network. Generally in OTN, each node maintains its own internal clock. In the case network failure or mesh restoration, diagnosing root cause requires highly experienced engineers or network operators to manually go through many logged network events and determine an order of the relevant events. Such a process is extremely tedious and fraught with error even in a small network and practically impossible in a large network.
An exemplary conventional solution may include a software tool to automate the event sequences in an offline manner. However, such a software tool has disadvantages including relying on internal, proprietary aspects of the event logging, accuracy within only several milliseconds, and generally lacking a systematic way of managing the system. Further, protocols such as Network Time Protocol (NTP), Global Positioning System (GPS), and Precision Time Protocol (PTP) (IEEE 1588-2002 and IEEE 1588-2008) could be implemented to synchronize the clocks of nodes across the network. However, such protocols are either not available or not cost effective in Time Division Multiplexing (TDM) networks. Also, such protocols may lack precision to within tens of milliseconds. Note, having accuracy within milliseconds inevitably causes improper ordering of network events. Furthermore, it may be desired in some cases that each node in the network maintain an independent clock (e.g., nodes are physically located in different time zones) and yet the sequential order of events needs to be determined.